Quoridor is a board game in which players must traverse a board in order to win. Each player is also given a number “walls” in order to block his opponent, or use in facilitating his path. Players take turns, and the person who starts first is randomly selected, unless otherwise noted. On a player’s turn, he may either move his given token one space horizontally or vertically, or he may place a wall. The walls cover the groove between two spaces. More details about game play will be mentioned later in this document.

The program will have three different Artificial Intelligence (AI) scripts. The program will also have the ability to host up to four players at one time or any combination of AI scripts or players. Must have a Hotseat Player. These AI’s will be written in VB.NET. The user must start the AI executable(s) outside the program.

2.) Current System

The current system is in the form of a board game. It is not computer based. We are not fixing an existing problem or updating a former system. Our objective is to design and implement a computerized version of Quoridor, the board game. Having a computerized version should help limit player confusion, by only allowing legal moves to be played.

3.) Functional Requirements

The basic function of our project is to provide the necessary procedure and interface for playing Quoridor on a computer. The specifics are governed by the rules for playing the classic version of Quoridor. When necessary, we will add or adjust rules to compensate for the computer platform specifications.

If one user is playing another over a network, one user will have to be designated as a “host,” and the other(s) a “client.” The host will set up the game for all the players. The client will type in the networking information to link up with the host.

Game Start

Once a user launches the game, it will prompt him or her with an option screen asking if he would like to start a new game, continue a game in progress, or join a game set up by a host computer. If the user selects to continue a game, he will select the game from a dialog box that comes up, and the game board with the previous conditions and settings will come up. If the user selects to join a game, the user will then type in the IP address and port number of the host computer.

If the host selects “New Game,” another screen is going to come up and ask how many human players and/or computer players are going to be in the game. Also this is where the host can change the options of the game. The options include:

- The board size (default is 10x10 spaces; range is from 6x6 to 12x12 spaces);

- The number of walls each player starts with (can be 0 to 144 per player).

Then the host selects the status of each player. For up to 4 players, the following choices may be made: 1.) Human; 2.) Remote/AI. After these selections are made, then a game board should appear on the screen.

The board would start with the number of character tokens depending on how many players were selected. These tokens will not actually start on the board – they will be placed outside predetermined edges of the board (see figure 3a). By default, turns will be taken in this order: Blue, Red, Green, Yellow.

Figure 3a - Placement of two player tokens at game start (6x6 board)

In-Game Flow

On a player’s turn, he may move one space or place a wall. After he does this, the next player continues this procedure, and so on. For the first move, the player may choose any space on his edge of the board to move. Once on the board, however, he may not move off the board except on the opposite side.

Option 1: Move Token

A player’s token may be moved either right, left, forward, or backward. A token may not be moved through a wall or on top of another token (see figure 3b).

In the case that there is a token in the way of the player, the player’s token may jump over the adjacent token and thus advancing 2 spaces. However, if there is a wall or another token behind or to the side of the adjacent token, that particular jump cannot be executed (see figure 3c).

Figure 3b - Illegal Moves

Figure 3c - Examples of moves and jumps over tokens

Option 2: Place Wall

A player may place a wall anywhere on the board, on the grooves, blocking exactly two spaces. Also, walls may not overlap or cross (see figure 3d). Finally, a player may not place walls in such a manner that an opponent will have no way to get to the other side of the board.

This will not be an issue, however. Our program will only allow legal moves to be played. When a player decides to play a wall, he will drag a wall onto the board horizontally or vertically. The walls will automatically be snapped to a grid. Wall placements that cross other walls or prevent a player from reaching the other side will not be permitted by the game.

Figure 3d - Illegal wall placements

Game End

A game is terminated in one of three ways.

The game is terminated when one of the players reaches their opponent’s side off the edge with their token. At this point, the game ends and the player is given the choice to play another game or quit.

Another way to end a game is through choice. If the user selects the end game option, he is asked if he would like to save his progress then exit, or just exit.

The only other way that a user may terminate a game is through disconnection. If in any way the user is disconnected from the network, the game will end immediately. All other players will then be given the option to save the game.

4.) Nonfunctional Requirements

4.1) Ability to Run on Windows

The program is expected to be run using the Windows operating environment. Since we are going to use Microsoft Visual Basic for implanting our program, operating on Windows is second nature.

4.2) Documentation

This RAD and upcoming documents describing the project will be used to specify the needs and constraints of the final product. These documents may be used by our client and manager to provide feedback or suggestions for improvements.

4.3) User Manual

We will provide a written user manual to help aid a user through the program. The manual will explain the basics of gameplay, how to use the interface, how to play over a network, and how to create and insert AI’s to be used as players.

4.4) Timely Gameplay

Algorithms and functions related to the game should run in an adequate amount of time, so that players do not have to wait for the computer to finish. Also, it is expected that players over a network will receive feedback from the opponent players with little time delay. The only delay should be the time to ponder moves and strategies and possibly network delay.

5.) Optional Features

The following is a list of features for our project that are extra, but not absolutely necessary. If the team finishes with extra time remaining at the end of the second semester, these features may be included.

4Time Clock – Limit each player’s turn to a fixed time to encourage quicker thinking.

4Undo Button – Undo a move from a player’s turn.

4Token Image Upload – Be able to upload one’s own picture file into their token.

4Interactive Help Box – Have a dialog box that can pop up explaining why a player may not place a token or wall in an illegal location.

6.) System Models

6.1) Sample Scenarios

Scenario Name: Start_1-livePlayer_Vs_1-AI_game

Actors: Brad – human player

Flow of Events:

1. Brad opens Quoridor on computer.

2. Brad selects “New Game.”

3. Brad selects “Human” on Player 1.

4. Brad selects “Remote/AI” on Player 2.

5. Brad finds and runs an AI module on the computer.

6. Brad selects the AI player from the Active Player drop-down box.

7. Brad clicks “Start Game” at the bottom. Tokens are chosen by default.

Scenario Name: PlayAnotherOrQuit_1-livePlayer_Vs_1-livePlayer_game

Actors: Drake – student in AI class (host)

Brad – human player (client)

Flow of Events:

1. Drake wins the game.

2. The message “Drake has won the game” appears on both computers along with three buttons: “Show Logs,” “New Game,” “Exit Quoridor.”

3. Brad selects “Exit Quoridor.”

4. Brad’s program closes.

5. Drake’s program displays “A player has left the game.”

6. Drake selects “Exit Quoridor.”

Scenario Name: MoveToken

Actors: Brad – human player

Flow of Events:

1. It is Brad’s turn.

2. Brad clicks on his token.

3. Brad drags his token one square to the right.

4. Token is grayed out – He can’t move there due to obstruction of a wall.

5. Brad drags token forward and releases button.

6. Brad’s token has moved forward.

7. Brad’s turn is over.

Scenario Name: PlaceWall

Actors: Brad – human player

Flow of Events:

1. It is Brad’s turn.

2. Brad clicks on a wall in his inventory.

3. Brad drags the wall to a place on the board.

4. The groove he selects will not allow a wall to be placed.

5. Brad drags the wall to a different location.

6. Wall is legal and is set in place.

7. Brad’s turn is over.

6.2) Flow diagram

7.) Glossary

AI (Artificial Intelligence) – refers to an algorithm module that runs interactively to act as a logical sequence of actions as reflected by the actions of the human brain.

board – the square platform where tokens and walls are placed upon in Quoridor.

client – the designated players/computers that stand by as the host sets up and manages the game.

game – a session of play starting with tokens off the board and ending when any token reaches the other side of the board respective to its starting edge.

groove – the “lines” that dissect the board, forming spaces.

host – the designated player(s)/computer that are responsible for setting up the game for all other players on different computers, referred to as “clients.”

jump – refers to the moving of a token past another token one unblocked space to any side of the other token.

player – any entity interacting with the board game – can be a live person or an AI module.

space – an individual square surrounded by grooves on the game board.

timer – refers to the timer that counts down the time left until the current player’s turn is over.

token – a game piece representing the player’s current position on the board.

turn – the procedure in which a player can move their token, place a wall, or pass their turn.

wall – a physical blockage which prevents players from moving across the groove where one is placed. Walls in Quoridor and in our implementation block two adjacent spaces in a line.

wall placement – placing of a wall in a valid location on the board

8.) Contributions

RAD Version 1.0:

Aaron O’Banion – Typed/edited these sections: Introduction, Current System, Functional Requirements.

Todd Astroth – Typed/edited these sections: Functional Requirements, Non-Functional Requirements, Optional Features, System Models, Glossary.

Chris Cobb – Contributed ideas for how to display and implement the game board.

Matt Stowe – Contributed ideas for how to implement gameplay using a graphical user interface.

Mark Williams – Designed the organized structure of RAD.

RAD Version 2.0:

Aaron O’Banion – Reworded and edited all trouble areas indicated by instructor on earlier version.

Todd Astroth – Proofread the document reworded by Aaron, updated minor details that were changed during course of the class.

RAD Version 3.0:

Todd Astroth – Updated sections pertaining to second semester. Changed drawings to screenshots. Created HTML version to be viewed online.

RAD Version 4.0:

Todd Astroth – Retyped/updated the following sections: Introduction, Game Start, Game End, Sample Scenarios. Added List of Figures.

Chris Cobb – Helped clear up confusion on the following areas: Introduction, Game Start, Game End

RAD Presentation:

Mark Williams

Matt Stowe

RAD Poster:

Chris Cobb

Website:

Chris Cobb